Management of Shared Access Network

ABSTRACT

Information from multiple sources can be communicated to a policy server. Based on that information, the policy server can determine allocation of bandwidth, transmission priority and/or other network resources based on preferences and/or service selections provided by a subscriber and communicate information about those determinations to other network elements for policy implementation. The information provided to a policy server for determining network resource allocation can include information about one or more applications executing at a customer equipment device, information about access network bandwidth usage, information about services for which one or more devices is authorized, and/or information about network conditions.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/170,245, titled “Management of Shared Access Network” and filed Jun.28, 2011, which is a continuation of U.S. patent application Ser. No.12/480,009, titled “Management of Shared Access Network” and filed Jun.8, 2009, which is incorporated in its entirety by reference herein.

BACKGROUND

It is now common for persons in homes and businesses to send and receivedata through a connection to one or more high speed data networks. Forexample, various telecommunications operators provide High-SpeedInternet (HSI) service to subscribing customers. The number of HSIcustomers is growing, and many customers are using HSI service forlonger periods and/or for more purposes. Although many operators havesystems with very substantial capacity, network bandwidth remains afinite resource that must be shared among numerous subscribers. Othernetwork resources that must be shared by those numerous subscribersinclude routers, gateways, servers and other discrete network elements,physical and/or logical ports at such network elements, cables (optical,coaxial, or otherwise) interconnecting network elements, etc.

Because most network resources are finite, system operators oftendevelop sets of rules to determine which users and/or services areallowed to use various resources, which users and/or services receivepriority, etc. These rule sets, or “policies,” have conventionally beenbased on isolated aspects of network operation. As a result, conflictsbetween policies can occur.

SUMMARY

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the invention.

In at least some embodiments, information from multiple sources iscommunicated to a policy server. Based on that information, the policyserver determines allocation of bandwidth, transmission priority and/orother network resources based on preferences and/or service selectionsprovided by a subscriber and communicates information about thosedeterminations to other network elements for policy implementation. Inat least some embodiments, the information provided to a policy serverfor determining network resource allocation includes information aboutone or more applications executing at a customer equipment device,information about access network bandwidth usage, information aboutservices for which one or more devices is authorized, and/or informationabout network conditions.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments of the present invention are illustrated by way ofexample, and not by way of limitation, in the figures of theaccompanying drawings and in which like reference numerals refer tosimilar elements.

FIG. 1 is a diagram of a network that includes devices configured toimplement network management techniques according to at least someembodiments.

FIG. 2A is an example of a database table stored in a memory of aprovisioning system server according to at least some embodiments.

FIG. 2B is an example of a database table stored in a memory of anInternet Protocol Data Record server according to at least someembodiments.

FIG. 3 is a block diagram explaining information flows to and from apolicy server according to at least some embodiments.

FIG. 4 is a flow chart explaining operation of a policy server,according to at least some embodiments, to manage network resources.

FIG. 5 is a partially schematic block diagram of a computing platformaccording to at least some embodiments.

DETAILED DESCRIPTION

Some embodiments are described in the context of services provided tosubscribers over access networks utilizing communication protocolsdescribed in one or more Data-Over-Cable Service InterfaceSpecifications (DOCSIS) standards. Said standards are known in the artand available from Cable Television Laboratories, Inc. (CableLabs®) ofLouisville, Colo. However, the invention is not limited to networksusing a specific type of communication protocol or a specific physicalcommunication medium.

FIG. 1 is a diagram of a network 10 that includes devices configured toimplement network management techniques according to at least someembodiments. Network 10 is a nationwide high speed data network thatincludes multiple access networks serving individual subscribers overhybrid fiber coaxial (HFC) plants and operated in accordance with one ormore DOCSIS protocols. Network 10 provides High-Speed Internet (HSI)data service and other services (e.g., cable television, Voice over IP(VoIP) telephone service) to subscribing customers. Typically, eachsubscriber location has one or more types of subscriber access device(AD) that is used to communicate data from customer equipment devices(CE) at subscriber locations to other points in network 10 (and/or topoints in other networks via network 10), and vice versa. Examples ofcustomer equipment devices include, but are not limited to, personalcomputers (PC), other types of computers, gaming consoles, video and/orvoice communication terminals, etc. Examples of access devices include,but are not limited to, cable modems, set top terminals, Media TerminalAdapters (MTA), etc.

Cable Modem Termination System (CMTS) 11 communicates with accessdevices in an access network portion of network 10. Although FIG. 1 onlyshows five access devices in the access network served by CMTS 11, thepresence of additional access devices is indicated by an arrow.Similarly, CMTS 12 communicates with multiple access devices in aseparate access network portion of network 10. As previously indicated,the access networks of CMTSs 11 and 12 are HFC DOCSIS networks. Forconvenience, optical nodes, splitters, amplifiers, and other elementsbetween CMTSs 11 and 12 and the access devices in their respectiveaccess networks are not shown in FIG. 1. Each CMTS forwards upstreamcommunications from the access devices in its access network to otherpoints in network 10, forwards data from other network 10 locationsdownstream to those access devices, and controls the ability of eachaccess device in its access network to communicate with network 10.CMTSs 11 and 12, as well as additional CMTSs (not shown), communicateover optical fibers 28 with a local market router 29. Local marketrouter 29, together with local market router 30 serving additional CMTSs(not shown in FIG. 1) and additional local market routers serving otherCMTSs (also not shown) communicate over optical fibers 31 with aregional router 32. Regional router 32 communicates over optical fiber35 with a backbone network router 37. Although not shown in FIG. 1,additional regional routers (with associated local routers, CMTSs, etc.)communicate with backbone network router 37 or other backbone networkrouters.

Also shown in FIG. 1 are a policy server 40, a provisioning system (PS)server 41, an Internet Protocol Data Record (IPDR) server 42, anapplication management (AM) server 43, a Simple Network ManagementProtocol (SNMP) server 44 and a PacketCable Multimedia (PCMM) server 45that communicate with each other and with other network 10 elements viaGigabit Ethernet links 46 with regional router 32. Deep PacketInspection (DPI) devices 13 and 14 are associated with CMTSs 11 and 12,respectively, and are described more fully below. Remaining elements inFIG. 1 are discussed below.

So as to avoid unnecessary drawing complexity, only a small number ofnetwork elements are shown in FIG. 1. Numerous additional routers,CMTSs, optical nodes, servers subscriber devices, etc., would be presentin an actual network. Each of servers 40, 41, 42, 43, 44 and 45 and DPIdevices 13 and 14 is a computing platform having processors and memoriesstoring instructions for operation as described herein, as well asnetwork interface hardware to facilitate communication with othernetwork elements. Although illustrated as separate devices, theoperations and functions of servers 40, 41, 42, 43, 44 and 45 and of DPIdevices 13 and 14 could be combined into fewer, or distributed acrossmore, computing platforms.

Each of the CE devices shown in FIG. 1 executes (or is configured toexecute) one or more application programs that communicate data acrossnetwork 10. For example, some PCs or other computers execute web browserapplications with which users of those computers access web sites andother services available on the Internet. Other computers executevarious other types of application programs that transmit and receivedata through network 10 via a cable modem or other type of subscriberaccess device. Examples of such programs include file sharing programs,games, email clients, clients for viewing IP television (IPTV) programcontent, streaming video applications, photo upload programs,network-based backup services, VoIP, etc. Some or all these variousapplications programs executing on CE devices communicate applicationdata in Internet Protocol (IP) packets. Those application data IPpackets may be further encapsulated in packets according to otherprotocols at different levels of the Open System Interconnection (OSI)reference model prior to transmission by a cable modem or other accessdevice. Similarly, data received by an access device from a CMTS innetwork 10 may require one or more levels of decapsulation to exposeincoming application data IP packets.

Policy server 40 receives information from multiple sources withinnetwork 10. That information includes information regarding applicationsexecuted by CE devices associated with various subscribers, informationregarding subscriber accounts, information regarding conditions invarious network locations, and other types of information. Based onreceived information, policy server 40 makes policy decisions aboutallocation of access network bandwidth and/or other network resources.Policy server 40 then communicates information about those decisions toother network devices so that the appropriate policies can beimplemented.

Provisioning system server 41 is one source of information input topolicy server 40. Provisioning system server 41 configures cable modemsand other subscriber access devices so as to control the servicesavailable to CE devices communicating through those access devices. Insome cases, provisioning system server 41 may also configure CE devices.Provisioning system server 41 can configure a subscriber access deviceor CE device using any of various techniques (e.g., by downloading aconfiguration file as a part of an initialization or rebooting process,in real time in response to a pending request for a service, etc.).

As part of its operations, provisioning system server 41 maintains adatabase of permitted services and other configuration data forsubscriber access devices receiving (or that may receive) HSI servicesin network 10. FIG. 2A shows an example of such a database in the formof a table 101. In some embodiments, one or more tables similar to table101 are maintained in a memory of provisioning system server 41. Thetables of FIGS. 2A and of 2B (discussed below) are merely examples ofhow data can be arranged in accordance with some embodiments. The actualformat of data and/or of the tables or other data structures used toorganize that data will vary among different embodiments. For example,databases corresponding to the tables of FIGS. 2A and 2B could benormalized, distributed throughout different tables, etc., as may berequired in connection with a desired implementation. So as to avoidunnecessary detail in the drawings, various fields in the tables ofFIGS. 2A and 2B are left blank where the type of data placed in one ofthose fields is described herein. Vertical ellipses in the tables ofFIGS. 2A and 2B indicate an arbitrary number of additional cells in aparticular column.

Each row in table 101 has fields holding provisioning data for a singlesubscriber account. In some embodiments, a subscriber is a person,corporation or other entity that has arranged to obtain access to, andone or more services from, network 10. Such arrangements typically,though not necessarily, involve a fee. An account is a construct used togroup various data items related to providing a subscriber with servicesin network 10. For example, a particular subscriber account in someembodiments corresponds to one or more specific access devices used tocommunicate with a CMTS of network 10, one or more services permittedfor those access devices, and various other data as described below. Anaccount may also correspond to a specific geographic address or otherpermanent location to which services are provided (e.g., an addresswhere an HFC plant coaxial cable drop terminates), though this need notbe the case. A user is an entity actually using an application programto communicate with network 10. A user will typically be a person, butthis is also not mandatory. A user may also, but need not, be asubscriber.

The first column of table 101 (“Acct ID”) holds unique subscriberaccount identifiers. Each field in the “AD1 MAC” column holds a mediaaccess control (MAC) address uniquely identifying a cable modem or otheraccess device corresponding to a subscriber account. MAC addresses foradditional access devices (if any) associated with an account are placedin fields of successive columns. Although only one such successivecolumn is shown (“AD2 MAC”), the presence of additional AD MAC columnsis indicated by a horizontal ellipsis. Each field in the “CE1 MAC”column holds a MAC address for a customer equipment device correspondingto a subscriber account. MAC addresses for additional customer equipmentdevices (if any) can be held in successive columns (“CE2 MAC”, etc.,with a horizontal ellipsis indicating the presence of additional similarcolumns). Each field in the “IP ver” column holds a value for theInternet Protocol version (e.g., IPv4 or IPv6) used by devicescorresponding to a subscriber account. Each field in the “BWup” columnholds a value for provisioned upstream bandwidth corresponding to asubscriber account. Each field in the “BWdn” column holds a value forprovisioned downstream bandwidth corresponding to a subscriber account.In some embodiments, certain types of upstream and downstreamcommunications from a subscriber are limited to certain maximum datacommunication rates. For example, one subscriber paying a basic rate maybe authorized to download certain kinds of data at 6 megabits per second(Mbps) and upload certain types of data at 1 Mbps, while anothersubscriber paying a slightly higher fee may be authorized to downloadcertain kinds of data at 8 megabits per second (Mbps) and upload certaintypes of data at 2 Mbps. Each field in the “TE” column holds a valueindicating whether a provisioned downstream data rate can be exceededfor a brief period of time to, e.g., download the initial portion of aweb page or streaming video. In some embodiments, table 101 may alsoinclude IP addresses such as are described in connection with FIG. 2B.

Subsequent fields in table 101 hold values that indicate whether aparticular subscriber is authorized to receive a particular service. Forexample, the “U” and “X” columns represent services that are discussedbelow in connection with various examples. The presence of an arbitrarynumber of additional columns for additional services is indicated byhorizontal ellipses before and after the “U” and “X” columns. Each ofthe fields in the service columns may, in addition to an indicator ofwhether a subscriber account is authorized to receive a service, includeinformation about the specifics of that service and/or configurationinformation for a CE and/or access device when that service is provided.In at least some embodiments, data in table 101 regarding services forwhich a particular subscriber is authorized are input as a result ofservice selections made by a subscriber over a web portal (describedbelow) or otherwise provided by the subscriber to the operator ofnetwork 10. Similarly, configuration data in table 101 forsubscriber-selected services (e.g., prioritization of subscriber datacommunication for such services) is also based on selections and choicesinput by the subscriber over a web portal or otherwise provided to thenetwork 10 operator.

Returning to FIG. 1, IPDR server 42 receives reports from access devicesor other network elements (e.g., CMTSs) and stores information regardingamounts of data transmitted to and received from individual accessdevices. FIG. 2B shows one example of a table 102 used (in someembodiments) to store such information in a database maintained in amemory of IPDR server 42. Each row in table 102 has fields holdinginformation about data communications associated with a specificsubscriber account. As discussed below, a single subscriber account mayhave more than one row in table 102 (and/or in other tables similar totable 102). The first column of table 102 (“Acct ID”) holds uniquesubscriber account identifiers. Each field in the “AD MAC” column holdsa MAC address uniquely identifying an access device corresponding to asubscriber account. If there are multiple access devices that correspondto a subscriber account (e.g., a subscriber has multiple authorizedcable modems, a cable modem and an MTA, etc.), table 102 may have aseparate row for each access device. Each field in the “AD IPaddr”column holds an IP address for an access device having its MAC addresson the same row. Each field in the “CE1 MAC” column holds a MAC addressfor a CE device currently communicating with network 10 through theaccess device identified on the same row. Each field in the CE1 IPaddrcolumn holds an IP address for the CE device having its MAC address inthe CE1 MAC column on the same row. Additional columns (indicatedgenerically by a horizontal ellipsis) have fields holding MAC and IPaddresses for additional CE devices communicating through a particularaccess device.

Each field in the “Flow ID” column holds an identifier for a DOCSISservice flow established between the access having its MAC address onthe same row and the CMTS serving the access network of that accessdevice. The “Dir” column holds a value indicating whether otherinformation in the row (discussed below) relates to upstreamcommunications from the access device or downstream communications tothe access device. Each field in the “Bytes Tr” column holds a valuesindicative of the number of bytes transmitted to or received from anaccess device having its MAC address on the same row in a preceding timeperiod (e.g., in the previous minute). In a similar manner, fields inthe “Pkts Fwd,” Pkts Del” and “Pkts Dsc” holds values indicative of thenumber of packets from (or to) an access devices in the same precedingperiod that have been forwarded, delayed or discarded. Separate versionsof table 102 for earlier time periods may be stored so as to construct ahistory for a particular access device. For example, the number of bytessent by an access device in the preceding 15 minutes could be determinedby consulting a current version of table 102 and by consulting 14 storedearlier versions of table 102 respectively corresponding to theimmediately preceding 14 minutes.

In at least some embodiments, each subscriber account will have aseparate row in table 102 for each unique combination of subscriberaccount, AD MAC, Flow ID and Dir values. For example, a subscriberaccount having Acct ID “S1” with a single cable modem having MAC address“CM1” and separate upstream and downstream flows FLup1 and FLdn1 wouldhave two rows in table 102: {S1 . . . CM1 . . . FLup1 . . . Up . . . }and {S1 . . . CM1 . . . FLdn1 . . . Dn . . . }. For subscriber accountswith multiple CE devices communicating through a particular accessdevice, table 102 could also include separate subfields in the Bytes Tr,Pkts Fwd, Pkts Del and Pkts Dsc columns to hold values that indicate theamount of transmitted bytes attributable to a each CE device, the amountof forwarded packets attributable to each CE device, etc. Alternately,separate rows could be inserted into table 102 for CE devices on aparticular access device.

Returning to FIG. 1, DPI devices 13 and 14 are located at and associatedwith CMTSs 11 and 12, respectively. Each of DPI device 13 and 14examines application data IP packets and determines applications thatcreated those packets. As explained above, an application executing on aCE device will typically encapsulate outgoing application data in an IPpacket. The CE device then communicates that data to an access devicefor upstream transmission to a CMTS of network 10. The CE device and/orthe access device may further encapsulate the application data IP packetinto (and segment the application data IP packet across) packetsaccording to protocols at other layers of the OSI reference model. Forpurposes of illustration, two types of DPI devices are shown in FIG. 1.DPI device 13 is an active DPI device. In particular, data flows betweenCMTS 11 and local router 29 or other upstream element flows through DPIdevice 13. Accordingly, DPI device 13 is able to affect such flows byprioritizing communications for various applications in accordance withsubscriber defined preferences. DPI device 14 is a passive DPI deviceand makes determinations about data packets flowing between CMTS 12 andupstream elements of network 10, but is not able to affect such dataflows.

Upon receiving an application data IP packet from an access device, aDPI device examines the IP header data in the packet and compares thatdata to one or more application signature files. Based on thatcomparison, the DPI device can determine what application created the IPpacket. In at least some embodiments, a DPI device can determine anyactive application such as a file sharing application, a streaming videoapplication, a photo upload application, a web browsing application,etc. As but one example, a DPI device may determine that a particulardestination address corresponds to a server that is accessed inconnection with several types of game applications. The DPI device maythen determine that a specific one of those game applications isindicated by a particular value in the Protocol field of an IPv4 packet(or in the “next header” field and one or more extension fields of anIPv6 packet). As another example, a DPI device can examine a TCP or UDPport number and determine the active application based on that portnumber. In at least some embodiments, and so as to maintain subscriberprivacy, a DPI device only examines header fields of an IPv4 or IPv6packet and does not examine any of the actual application data (or otherdata) that may be carried in the payload data field of an IP packet. Inat least some such embodiments, determinations of active applicationsare only made so as to implement subscriber-defined preferences, andthose determinations are not used for any other purpose and records ofsuch determinations are not retained any longer than is necessary toimplement those subscriber-defined preferences.

A DPI device need not maintain signature files matching everyconceivable type of application that a subscriber might use. Instead,DPI devices in some embodiments identify applications for which someaction might be taken by policy server 40. A DPI device could simplyignore IP packets having headers that do not match an application in theapplication signatures files of that DPI device. In some embodiments,each of DPI devices 13 and 14 maintains its own copy of an applicationsignature database and forwards information about an identifiedapplication to policy server 40. In other embodiments, a DPI devicesimply extracts the information from one or more IP packet header fieldsand forwards that extracted information to policy server 40. Policyserver 40 then compares that information with application signaturefiles to identify an application.

Based on information in the header of an application data IP packet,and/or information in header(s) of one or more additional packetsencapsulating that IP packet, a DPI device can also determine the accessdevice sending the IP packet. The DPI device may in some embodimentsalso determine the CE device executing the application that generatedthe IP packet. Information regarding the access device and/or CE deviceis also provided to policy server 40.

In at least some embodiments, information about individual applicationprograms is also stored in a database maintained in a memory ofapplication management server 43. In some embodiments, applicationmanagement server 43 can be implemented using a Bandwidth on Demand(BOD) application manager (available from Camiant, Inc. of Marlborough,Mass.) having additional programming to carry out operations such as aredescribed herein. In some cases, the application information in server43 may relate to the performance preferences and/or needs of anapplication program executing on a CE device. For example, a gameapplication executing on computer or game console may require real-timecommunications with a game server, and thus be sensitive to latency,jitter and packet loss. However, that same application may only transfersmall amounts of data, and thus not require large amounts of bandwidth.Conversely, a file sharing application may consume a large amount ofbandwidth for bulk data transfers but be less sensitive to minor delays.Still other applications (e.g., streaming video content) may requirelarge data transfers and be sensitive to certain types of delay.

In addition to information about preferences and/or requirements forindividual application programs, application management server 43 mayalso store information regarding the preferences and/or needs of a thirdparty providing services in connection with a particular application.Returning to the game application example, a provider operating a gameserver for that application may transmit information to applicationmanagement server 43 about the total number of subscribers currentlyaccessing the game server, the regions in which those subscribers aredistributed, and the overall bandwidth needed to accommodate thosesubscribers' use of the game server. That same game provider may alsooperate “mirror” game servers and have the ability to serve individualgame playing users from any of those servers. However, the game providermay also serve game players outside of network 10, and an operator ofnetwork 10 may thus not know the current load levels of each mirrorserver. Accordingly, the game provider could periodically transmitinformation about each mirror server's load state to applicationmanagement server 43 so that communications with game players in network10 can be routed to different servers if appropriate.

SNMP server 44 receives information about load levels for CMTSs, routersand other network elements, information about device outages, and otherinformation regarding the conditions of various elements throughoutnetwork 10. For example, SNMP server 44 may receive and storeinformation about the amount of packets and/or bytes received andtransmitted over various router interfaces in network 10. Informationmaintained by SNMP server 44 may also be accessed by policy server 40.

As indicated above, policy server 40 receives information from multiplesources within network 10, makes policy decisions about allocation ofaccess network bandwidth and/or other network resources based on thatreceived information, and communicates information about those decisionsto other network devices. FIG. 3 is a block diagram explaininginformation flows to and from policy server 40 according to at leastsome embodiments. A subscriber (or an individual user associated with asubscriber) provides input through web portal 39 to select services, setpreferences and/or priorities and/or otherwise configure services, etc.The resulting user-defined configuration data is provided via one ormore intermediate network elements (not shown) to provisioning systemserver 41, application management server 43 and/or policy server 40. Inother embodiments, subscriber input is received in another manner (e.g.,entry by a customer service representative receiving subscriber input bytelephone). Provisioning system server 41 provides subscriber accountinformation (e.g., information about services and/or devices associatedwith an account) to policy server 40. IPDR server 42 providesinformation about bandwidth usage by access devices corresponding to asubscriber account. A DPI device from a subscriber's access networkprovides information about applications executed by CE devicescorresponding to a subscriber account. Application management server 43also provides information about applications executed by such devicesand/or regarding network resources related to such applications. SNMPserver 44 provides status information about various elements in network10.

After making decisions based on information received from varioussources, policy server 40 communicates information about those decisionsto one or more network elements. In some cases, policy server 40 willforward instructions to PCMM server 45 over a Common Open Policy Service(COPS) interface. In response to those instructions, PCMM server 45 willforward instructions (e.g., a PCMM Gate-Set request message) to a CMTSthat cause the CMTS to change the manner in which data communicationsfrom or to an access device are managed. In some embodiments, two basicflow treatments sent from policy server 40 to a CMTS include a change inflow priority and setting a maximum or minimum bandwidth cap. Policyserver 40 may also forward instructions to an active DPI device such asdevice 13 for purposes of network management; that active DPI device maybe the same device that provided the application data to policy server40 used to make a policy decision. In response to messages from policyserver 40, for example, DPI device 13 may reprioritize data flows so asto implement a subscriber-requested preference. DPI device 13 couldeffect such reprioritization by use of different data forwarding queueswithin DPI device 13 and/or by adjusting priority markings in a packetheader (e.g., the DiffSery field of an IP packet header). Policy server40 may also communicate with routers and/or various other networkdevices (shown generically in broken lines) to implement policydeterminations.

FIG. 3 does not illustrate all aspects of all embodiments. In someembodiments, for example, policy server 40 may receive informationinputs from sources other than those shown on the left side of FIG. 3.In some cases, policy server 40 may only receive information from someof the sources shown (e.g., only from a provisioning server, a DPIdevice and an IPDR server). There might also be multiple provisioningsystem servers, multiple IPDR servers, etc. providing informationregarding a single subscriber account. Policy server 40 might also sendcommunications other than policy-implementation communications (e.g.,queries) to a provisioning server, IPDR server, DPI device, applicationmanagement server, SNMP server, or other device.

As but one example of policy server 40 operation in one embodiment,assume that CE device 16 (FIG. 1) is a personal computer (PC) executinga game application program (“application X”) and an email applicationprogram (“application Y”), and that CE device 17 is another PC executinga web browser (“application Z”). CE/PC 16 communicates data forapplications X and Y, and CE/PC 17 communicates data for application Z,via cable modem access device (AD/CM) 15. Further assume that subscriberA corresponding to AD/CM 15 has made arrangements with the operator ofnetwork 10 to receive a gaming service (“service X”) in whichcommunications for application×receive priority over communications forother applications that might also be running on CE/PC 16, CE/PC 17, CE18 or other CE devices communicating with CMTS 11 through AD/CM 15.Accordingly, the field in the “X” column of table 101 (FIG. 2A)corresponding to the subscriber A account would include an indicatorthat the subscriber is authorized to receive service X.

When CE/PC 16 initially begins executing application X, one or more IPpackets containing application X data are sent by CE/PC 16, via AD/CM15, addressed to game server 61 operated by a third party game provider.When those IP packets are received at CMTS 11, DPI device 13 examinesone or more fields in the headers and determines that the packets areassociated with application X. DPI device 13 then communicates to policyserver 40 that application X is executing on a device communicatingthrough AD/CM 15. DPI device 13 may also inform policy server 40 of thespecific device (CE/PC 16) on which application X is running DPI device13 also examines headers in IP packets originating from applications Yand Z and provides similar information about those applications topolicy server 40.

Policy server 40 then queries IPDR server 42 and receives informationregarding how much bandwidth is being consumed by applications X, Y andZ in the upstream and/or downstream channels between AD/CM 15 and CMTS11. IPDR server 42 also provides information about the amount ofavailable bandwidth on those channels. In response to another query,provisioning system server 41 provides information to policy server 40about the applications and services authorized for the subscriber Aaccount, information about provisioned upstream and downstream bandwidthfor the subscriber A account, etc. Application management server 43provides information to policy server 40 regarding the networkperformance preferences and/or requirements of application X. In thecurrent example, that information includes average expected data ratefor application X, maximum burst data rate for application X, and jitterand latency requirements. Application management server 43 may alsoprovide information to policy server 40 regarding load levels of gameserver 61. SNMP server 44 provides information to policy server 40regarding any outages and regarding load levels and other conditionsrelated to CMTS 11, routers 29, 32 and 37, and other elements of network10.

With the received information from these various sources, policy server40 determines that subscriber A is authorized to receive service X.Policy server 40 further determines that there is sufficient availablebandwidth on the up- and downstream channels between AD/CM 15 and CMTS11 to accommodate, within the limits of subscriber A's provisionedbandwidths, the requirements of application X and at least some of therequirements of applications Y and Z. Policy server 40 also determinesthat there is no conflict between policies associated with service X andother policies applicable to subscriber A. For example, policy server 40may evaluate whether service X (which prioritizes data traffic forapplication X) would conflict with a policy requiring application Y orapplication Z to receive highest priority. Based on information fromapplication management server 43 and SNMP server 44, policy server 40may also determine whether the links in network 10 to game server 61 cansatisfy the requirements of application X.

In response to these various determinations, policy server 40communicates information regarding allocation of network 10 resources tovarious network elements. In particular, policy server 40 instructs PCMMserver 45 that data for application X at CE/PC 16 should have higherpriority than data for applications Y and Z so that the latency, jitterand other preferences associated with application X can be satisfied.PCMM server 45 then sends one or more Gate-Set request messages to CMTS11. In response to those Gate-Set requests, CMTS 11 places downstreamdata for game X in a transmission queue having higher priority thanqueue(s) into which downstream data applications Y and Z are placed.CMTS 11 similarly gives a higher priority to application X and lowerpriority to applications Y and Z when granting upstream transmissionopportunities to AD/CM 15. In some embodiments, policy server 40 couldsend instructions to DPI server 13 and/or other network elements (e.g.,upstream routers) to cause some or all of the prioritization ofapplication X data relative to data of applications Y and Z to beperformed at DPI device 13 and/or another network element.

In some embodiments, and continuing the previous example, there may be abasic priority level applicable to user data traffic in an accessnetwork, and multiple additional priority levels that are successivelyhigher than the basic priority. Based on application network performanceinformation received from application management server 43 (i.e., theaverage expected data rate for application X, maximum burst data ratefor application X, and jitter and latency requirements), policy server40 selects the lowest of those multiple additional priorities that willsatisfy the performance preferences for application X.

As another example of policy server 40 operation in response to variousinformation inputs, assume that CE device 20 (FIG. 1) is a personalcomputer (PC) executing a bandwidth-intensive application such as a filesharing client (“application U”). Subscriber B, associated with cablemodem access device (AD/CM) 19 through which CE/PC 20 communicates withnetwork 10, has made arrangements with the operator of network 10 toreceive a provisioned bandwidth augmentation service (“service U”). Inparticular, service U allows subscriber B to upload and/or download dataat rates above the provisioned up- and downstream bandwidths forsubscriber B if there is available channel capacity between AD/CM 19 andCMTS 11. When CE/PC 20 initially begins executing application U, one ormore IP packets containing application U data are sent by CE/PC 20, viaAD/CM 19, to CMTS 11. When those IP packets are received, DPI device 13examines one or more fields in the headers and determines that thepackets are associated with application U. DPI device 13 thencommunicates to policy server 40 that application U is executing on adevice communicating through AD/CM 19. DPI device 13 may also informpolicy server 40 of the specific device (CE/PC 20) on which applicationU is running.

Policy server 40 then queries IPDR server 42 and receives informationregarding how much bandwidth is being consumed by other applications (ifany) executing at CE devices associated with AD/CM 19 and/or subscriberB. IPDR server 42 also provides information about the amount ofavailable bandwidth on the up- and downstream channels between AD/CM 19and CMTS 11. Provisioning system server 41 provides information topolicy server 40 about the applications and services authorized for thesubscriber B account, information about provisioned upstream anddownstream bandwidth for the subscriber B account, etc. Based on theinformation from DPI device 13, IPDR server 42 and provisioning systemserver 41, policy server 40 determines that subscriber B is authorizedto receive service U. Policy server 40 further determines that providingservice U to subscriber B will not conflict with another policy thatmight also apply to subscriber B. For example, a policy may require thattotal communication on an access network channel not exceed a certainpercentage of maximum capacity. If data traffic from other accessdevices on a particular channel is sufficiently high, providing serviceU to subscriber B using that same channel might result in a policyconflict.

In the present example, policy server 40 determines that there issufficient available bandwidth on the up- and/or downstream channelsbetween AD/CM 19 and CMTS 11 to permit communication at a data rateabove the provisioned up- and downstream bandwidths of subscriber B.Policy server 40 further determines that there are no other applicationscurrently executing at CE/PC 20 or other subscriber B devices thatrequire significant bandwidth. Based on these various determinations,policy server 40 further determines there is no policy conflict ifservice U is provided.

In response to these various determinations, policy server 40communicates information regarding allocation of network 10 resources toPCMM server 45. In particular, policy server 40 instructs PCMM server 45that data for application U at CE/PC 20 should be transmitted to (orreceived from) AD/CM 19 at a higher rate. PCMM server 45 then sends oneor more Gate-Set request messages to CMTS 11 that cause CMTS 11 totransmit downstream application U data to AD/CM 19 at a higher thannormal rate and/or to grant upstream transmission opportunities to AD/CM19 for application U data at a higher than normal rate.

In some embodiments, the “U” column field in table 101 (FIG. 2A) mayhold a value indicating how many times a subscriber has invokedapplication U in some preceding period (e.g., in the last 30 minutes).As part of its decision process, policy server 40 could then determineif the number of application U uses in the preceding period exceeds somemaximum value. If application U has already been used the maximum numberof times, policy server 40 could then determine that the subscriber willnot be allowed to exceed provisioned bandwidth.

As yet another example of policy server 40 operation in response tovarious information inputs, assume that CE device 22 (FIG. 1) is apersonal computer (PC) executing an arbitrary application requiringInternet access. CE device 23 at the same location is another PC alsoexecuting one or more applications requiring Internet access. One of theapplications executing at CE/PC 23 may or may not be the same as thearbitrary application executing at CE/PC 22 (e.g., CE/PC 22 and CE/PC 23may each be executing an instance of a web browser). Subscriber C,associated with cable modem access device (AD/CM) 21 through which CE/PC22 and CE/PC 22 communicate with network 10, has made arrangements withthe operator of network 10 to receive a service by which subscriber C ispermitted to designate an application to be prioritized (“service S”).Although not shown in FIG. 2A, information about a subscriber accountauthorization for service S could be included in one or more additionalcolumns of table 101. Service S allows an authorized subscriber todesignate an application (or an application executing on a specific CEdevice) that is to be prioritized relative to other applications (orother application/device combinations) corresponding to the subscriber'saccount. This would, for example, permit one member of a family using aweb browser on CE/PC 22 for business purposes to receive datatransmission priority over other members of the family using theinternet for recreational purposes.

CE/PC 22 could invoke service S in various manners. For example, a userof CE/PC 22 could invoke a separate service S application, input theidentity of the application and CE device to be prioritized, and send aprioritization request message to network 10. That separate service Sapplication would then be identified by DPI device 13 based on packetheader information. A user could alternatively have previouslyidentified the application and CE device to be prioritized (e.g., usinga web portal of the network 10 operator). When a session with theprioritized application on the prioritized device is begun, theprioritized application and CE device are identified by DPI device 13based on packet header information.

Upon receiving information from DPI server 13 indicating service Sinvocation by subscriber C, and based on information received fromprovisioning system server 41 indicating service S is authorized forsubscriber C, policy server 40 determines that one or more applicationsat the subscriber C location (e.g., an application the subscriber hasspecified or an application on a CE device the subscriber has specified)should be prioritized relative to other applications executing on CEdevices at the subscriber location. In response to these variousdeterminations, policy server 40 communicates information regardingallocation of network 10 resources to PCMM server 45. In particular,policy server 40 instructs PCMM server 45 that data for the prioritizedapplication at CE/PC 22 should be transmitted to (or received from)AD/CM 19 before data for other applications. PCMM server 45 then sendsone or more Gate-Set request messages to CMTS 11 that cause CMTS 11 totransmit downstream data for the prioritized application to AD/CM 21before sending data for other applications, and to grant upstreamtransmission opportunities to AD/CM 21 for the prioritized applicationbefore granting transmission opportunities for other applications and/orCE devices.

Service S could be implemented in various manners. For example, a singleservice flow could be assigned to AD/CM 21, with data for eachapplication executing on PC/CE 22 and PC/CE 23 queued differently basedon its priority. Service S could also be implemented by assigningseparate service flows for PC/CE 22 and PC/CE 23, with the service flowfor PC/CE 22 having a higher priority than the service flow assigned toPC/CE 23. A separate service flow for PC/CE 22 could also be assigned aguaranteed bandwidth.

FIG. 4 is a flow chart explaining operation of policy server 40,according to at least some embodiments, to manage network resources. Thealgorithm of FIG. 4 is carried out by one or more processors of policyserver 19 according to instructions stored in a memory of policy server40 as executable code and/or according to hardwired logic instructionswithin the processor(s) of policy server 40. Multiple instances of thealgorithm of FIG. 4 are simultaneously performed by policy server 40with regard to different subscriber accounts in network 10. Beginning inblock 151, policy server 40 receives information from a DPI device aboutan application executing at a CE device corresponding to a subscriberaccount. In block 152, policy server 40 receives information from anIPDR server or other source regarding usage of communication carryingcapacity (bandwidth) in access network channel(s) by devicescorresponding to that subscriber account. In block 153, policy server 40receives provisioning information regarding that subscriber account(e.g., information about authorized services for the subscriber). Inblock 154, policy server 40 receives information from an applicationmanagement server or other source regarding network performancerequirements and/or preferences for the application about whichinformation was received in block 151. In block 155, policy server 40receives information from an SNMP server and/or other sources regardingother network conditions.

In block 156, based on information received in blocks 151 through 155,policy server 40 determines whether any network resources should beallocated, and if so, what that allocation should be. For example, andas indicated above, policy server 40 may determine if a subscriber isauthorized to receive a particular service. Policy server 40 may alsodetermine if providing a particular service to the subscriber wouldrequire implementing a policy that could conflict with another policyapplicable to the subscriber. Illustrations of such determinations areprovided above in connection with previous examples. As but anotherexample, policy server 40 might determine that a user at a subscriber'sCE device is currently executing a first application that requires afirst amount of bandwidth and is seeking to use a second applicationrequiring a second amount of bandwidth, but that the combined first andsecond bandwidth requirements exceed a maximum available bandwidth.

In block 157, policy server 157 communicates information to otherdevices regarding network resource allocation. In some cases, and asdescribed in connection with previous examples, those communications mayinclude instructions to a PCMM server, an active DPI device and/or otherdevices so as to prioritize certain data communications to thesubscriber and/or to increase bandwidth available to the subscriber. Insome cases, the communication in block 157 may be a notification to asubscriber's CE device that a requested service will not be allowed(e.g., because of a policy conflict).

All operations shown in FIG. 4 will not be performed in every case. Forexample, some services may not require policy server 40 to obtaininformation regarding bandwidth consumption from an IPDR server or othersource, and block 152 is skipped. Other blocks in the algorithm of FIG.4 can be skipped in other cases.

In at least some embodiments, each of policy server 40, provisioningsystem server 41, IPDR server 42, application management server 43, SNMPserver 44, PCMM server 45, DPI device 13 and DPI device 14 can beimplemented as multiple computing platforms for redundancy and/or toincrease the amount of analysis, data storage and other operations beingperformed simultaneously. FIG. 5 is a partially schematic block diagramof a computing platform that can act as one of policy server 40,provisioning system server 41, IPDR server 42, application managementserver 43, SNMP server 44, PCMM server 45, DPI device 13 or DPI device14. The computing platform includes one or more hardware interfaces 205that provide physical connections by which the computing platformcommunicates with other devices in network 10. In at least someembodiments, hardware interfaces 205 include one or more Ethernet cards.The computing platform further includes memory 206 for storinginstructions and data and a processor 207 for executing instructions andcontrolling operation of the computing platform. Although a single blockis shown for memory 206 and a single block shown for processor 207,memory and computational operations of the computing platform couldrespectively be distributed across multiple memory devices and multipleprocessors located within the computing platform and/or across memoryand processors located on multiple platforms. Memory 206 may includevolatile and non-volatile memory and can include any of various types ofstorage technology, including one or more of the following types ofstorage devices: read only memory (ROM) modules, random access memory(RAM) modules, magnetic tape, magnetic discs (e.g., a fixed hard diskdrive or a removable floppy disk), optical disk (e.g., a CD-ROM disc, aCD-RW disc, a DVD disc), flash memory, and EEPROM memory. Processor 207may be implemented with any of numerous types of devices, including butnot limited to one or more general purpose microprocessors, one or moreapplication specific integrated circuits, one or more field programmablegate arrays, and combinations thereof. In at least some embodiments,processor 207 carries out operations described herein according tomachine readable instructions stored in memory 206 and/or stored ashardwired logic gates within processor 207. Processor 207 communicateswith and controls memory 206 and interfaces 205 over one or more buses208.

Embodiments of the invention include a machine readable storage medium(e.g., a CD-ROM, CD-RW, DVD, floppy disc, FLASH memory, RAM, ROM,magnetic platters of a hard drive, etc.) storing machine readableinstructions that, when executed by one or more processors, cause aserver or other network device to carry out operations such as aredescribed herein. As used herein (including the claims), amachine-readable storage medium is a physical structure that can betouched by a human. A modulated signal would not by itself constitute amachine-readable storage medium.

The foregoing description of embodiments has been presented for purposesof illustration and description. The foregoing description is notintended to be exhaustive or to limit embodiments of the presentinvention to the precise form disclosed, and modifications andvariations are possible in light of the above teachings or may beacquired from practice of various embodiments. The embodiments discussedherein were chosen and described in order to explain the principles andthe nature of various embodiments and their practical application toenable one skilled in the art to utilize the present invention invarious embodiments and with various modifications as are suited to theparticular use contemplated. The features of the embodiments describedherein may be combined in all possible combinations of methods,apparatuses, modules, systems, and machine-readable storage media. Anyand all permutations of features from above-described embodiments arethe within the scope of the invention.

1. A method comprising: receiving data.